Like any kind of apps, JavaScript apps also have to be written well.
Otherwise, we run into all kinds of issues later on.
In this article, we’ll look at some best practices we should follow when writing Node apps.
Generating Random Strings Using Node.js
We can generate random strings with the cryptoRandomBytes method.
Other methods might not be as random as we think.
And this makes applications vulnerable to cryptographic attacks.
Authentication
We should use multi-factor authentication for important services and accounts.
Passwords should be rotated frequently, including SSH keys.
Strong password policies should be applied everywhere.
Don’t ship apps with any default credentials.
Only standard authentication methods like OAuth, OpenID, etc should be used.
Basic auth is insecure so we shouldn’t use it.
Auth endpoints should have rate-limiting so attackers can’t use brute force attacks to attack our app.
When there are login failures, we shouldn’t let users know that username or password validation failed.
The error message should be generic to avoid guessing.
Using a centralized user management system is also a good idea to avoid multiple accounts.
Access Control
The principle of least privilege should be followed.
This means the least amount of power should be granted to a user for them to do their work.
Never work with root accounts except for account management.
All instances or containers should be run with a role or service account.
We can assign permissions to groups and not to users.
This makes permission management easier and more transparent.
Security Misconfiguration
Access to the production environment internals should be through the internal network only.
This can be done via SSH or other ways.
Internal services should never be exposed.
Internal network access should be restricted to a few users.
If we’re using cookies, we should configure it to the secured mode where it’s sent over SSL only.
They should also be configured to the same site so only requests from the same domain will reply to the given cookies.
We should also set cookies to HttpOnly to prevent client-side JavaScript code from accessing the cookies.
Servicer should be protected with strict and restrictive access rules.
Threats should be prioritized with security threat modeling.
DDOS attack protection should be added with HTTP and TCP load balancers.
We should perform penetration tests periodically.
Sensitive Data Exposure
We should only accept SSL/TLS connections and enforce strict transport security with headers.
Networks should be separated into subnets to ensure each node has the least access permissions.
All services and instances that don’t need Internet access should be blocked from accessing the Internet.
Secrets should be stored in vault products like AWS KMS, Google Cloud KMS, etc.
Sensitive instance metadata should be locked down with metadata.
Data that are in transit should be encrypted.
Secrets shouldn’t be in log statements.
Plain passwords shouldn’t be shown on front end and the back end shouldn’t store sensitive information in plain text.
Components With Known Security Vulnerabilities
Docker images should be scanned for known vulnerabilities.
Automatic patching and upgrades should be enabled to avoid running outdated OS versions without security patches.
Users should have the ID, access, and refresh tokens so that access tokens are refreshed periodically and are short-lived.
Conclusion
There’re many things to think about with security to secure our data.
To keep strict access control, we’ve to do all the items described and more.
